home *** CD-ROM | disk | FTP | other *** search
- Path: news.th-darmstadt.de!news
- From: enno@inferenzsysteme.informatik.th-darmstadt.de (Enno Sandner)
- Newsgroups: comp.lang.c++
- Subject: Re: Circular Usage (forward declaration?)
- Date: 17 Apr 1996 20:04:01 +0200
- Organization: Fachbereich Informatik, TH Darmstadt
- Sender: enno@kitz.inferenzsysteme.informatik.th-darmstadt.de
- Message-ID: <lt3f62u3qm.fsf@kitz.inferenzsysteme.informatik.th-darmstadt.de>
- References: <MRW.96Apr16184800@tobago.siemens.ch>
- <ltu3ykovzc.fsf@kitz.inferenzsysteme.informatik.th-darmstadt.de>
- <31747631.5970@datalytics.com> <MRW.96Apr17104121@tobago.siemens.ch>
- NNTP-Posting-Host: kitz.intellektik.informatik.th-darmstadt.de
- In-reply-to: mrw@tobago.siemens.ch's message of 17 Apr 1996 08:41:21 GMT
- X-Newsreader: Gnus v5.1
-
- In article <MRW.96Apr17104121@tobago.siemens.ch> mrw@tobago.siemens.ch (Waeckerlin Marc) writes:
-
- Thank you for the answers.
-
- I know this way, but it does not work in my case, since the members "x"
- absolutely must be no pointers.
- Speaking more exactly, they are pointers, but they are smart pointers.
- In another example, you could get somnething like this, where "CPointer"
- is a smart pointer:
-
- class CCompany
- {
- protected:
-
- CPointer<CEmployee> m_emp;
-
- public:
-
- set(CEmployee &p_emp)
- {
- m_emp = &p_emp;
- }
- };
-
-
- class CEmployee
- {
- protected:
-
- CPointer<CCompany> m_comp;
-
- public:
-
- set(CCompany &p_comp)
- {
- m_comp = &p_comp;
- }
- };
-
- If your smart-pointer can handle polymorphism, you may introduce abstract
- classes representing the interfaces for the concrete classes CCompany and
- CEmployee, say CCompanyItf and CEmployeeItf. The concrete classes would
- inherit public from these abstract classes to express the conformance to
- the described interfaces. Finally CCompany would maintain a pointer to a
- CEmployeeItf and CEmployee a pointer to CCompanyItf instead. This adds some
- slightly additional overhead, because each function will become virtual.
- Or you may use the common technique to hide implementation details by
- putting all data-members in a dynamicly allocated structure. For instance
- the modified CCompany class may look like
-
- headerfile:
- class CCompanyImp;
-
- class CCompany {
- protected:
- CCompanyImp* imp_;
-
- public:
- CCompany();
- CCompany(const CCompany&);
- ~CCompany();
- CCompany& operator = (const CCompany&);
- void set(CEmployee &p_emp);
- };
-
- implementation-file:
- class CCompanyItf {
- friend class CCompany;
- CPointer<CEmployee> m_emp;
- };
-
- CCompany :: CCompany() : imp_(new CCompanyImp()) {}
- // copy-ctor, dtor, assignment-op left out ...
- void CCompany :: set(CEmployee& p_emp) { imp_->m_emp=p_emp; }
-
- Of course this also adds some overhead for dereferencing the pointer.
- But both are IMO reasonable solutions to resolve the problem of cyclic
- dependencies.
-
- Enno
-